A model for software sizing

There is a need for better software sizing models. Two existmg models. namely Albrecht's Function Point Analysis and DeMarco's System BANG are examined as car.didate models and some of their deficiencies noted. An architecture for a systems sizing model is presented, its major components are identified, and their general functions described. L 1.0 The need for better software s izim models. Notwithstanding the enormous complexity of the problem of software costing, considerable progress has been made in software cost estimation based on a given software size, notably in the COCOMO model IBOE8 1 1. Experience, however, still plays a large part in successful size and cost estimation [BOE82]. Most computer installations are too small to have a separate cost estimation group, have limited access to experts experienced in size estimation. and have inadequate historical records. To make matters worse, some sizing/costing methods are installation-dependent, even to the extent of the basic unit of measurement being defined somewhat differently within the same basic model (DEM821, IALB791, ICOL821, IRUD831. Many managers are understandably uneasy and defensive abou? the basis of their estimates. As shown in Figure 1 , software sizing is at present the weakest link in the software cost estimation chain. Boehm IBQE8 11 discusses common reasons for inaccurate sizing. There is a need for software sizing models with levels of reliability similar to those observed for COCOMO IBOEBII. DeMarco [DEM82] defines rhe qualities of a good metric in this context as being measurable, independent (objective), accountible, precise, consistent and available early enough to be useful. SOFTWARE SlZlNO AND COSTING d comparatively wsak. comparatively strong In the past several years there have been some useful attempts to solve the sizing problem, particularly for commercial data processing systems In 1979 Albrecht IALB791 first introduced Function Point Analysis [FPAIHe believed that lines of code as a measure was too language-dependent and d instead measured the 'size' of a system in function points. In 1982 DeMarco IDEM821 published work on a sizing and costing method that used another unit to measure system size, which he called System BANG. FPA appears to be the more widely used of the two, possibly because it is much simpler to use. It is popular in IBM installations and is increasingly being used for sizing systems written in fourth generation languages. 2-0 Recent attempts to solve the sizing problem 2.1 Function Point Analysis I The function point measure is said to be based on the user's view of the system and it IF claimed that non-DP users can evaluate the measure IRUD83). The raw function point count is based on the number and complexity of : external input rypes external output types logical internal file types external interface file types external inquiry types. L This initial count is summed and later modified using 14 system adjustment factors to get a final function point count for the system IALB84, ALBBS]. Since many of' these system adjustment factors could be classed as cost drivers rather than ~ i z e drivers, the final function point count is more a measure of total effort than of size. FPA was used by Albrecht to compare productivity between projects that were written in different languages and used different technology. He used the average number of lines of code required to develop a function point to show the relative productivities of COBOL. PL/ I and DMS/VS IALB791. Other writers (RUD831 have used FPA to produce productivity figures for certain 4GLs. FPA treats the system as if all the inputs, outputs. queries, etc., flow into or out of a single black box process. Thus the raw function point. count does not measure the effects of complex processing. FPA tries tit overcome this obvious flaw by its use of system adjustment factors. Here the effects of interactive interfaces and complex processing on the system as a whole, together with other cost drivers, are used to modify the raw function point count. We consider these adjustment factors to be the weakest part of the L method. They are small additive corrections with equal maximum weight (an unlikely situation in the real world) and with a relatively small total effect, having a possible range of from -35% to +35% adjustment. Given the subjectivity of the adjustment criteria; afid the tendency of assessors towards means, the overall adjustment of the raw function points will rarely be more than 15%. These adjustment factors seem rather old-fashioned as they tend to be aimed at batch processing systems. Albrecht and Gaffney [ALB83] have also used function points, and counts of unique I/O operands, as estimators for delivered source instructions, and effort, in COBOL and PL/I programs. 2.2 DeMarco's System BANG. DeMarco in [DEM82, DEM84) suggested another measure of system size called System BANG. This measure is calculated from Structured Analysis specifications. The system specifications are developed down to functional primitives (FP). A FP is described as "a trivial piece". "too small to justify further partitioning" (DEM841. The number of input and output tokens at the boundary of each FP is summed and then used to adjust the value of the L FP. DeMarco provides a table of weighted FP increments for this adjustment and states that the values are based on Halstead s volume/vocabulary relationship IHAi771. Each FP is then given an emglrical Complexity Correction Factor. This factor depends on the class af primitive function DeMarco defined 16 classes (a beginning set) of primitives although he suggests that the Correction Factor value for some may be less likely t.o remain invariant than for others. Each weighted FP is multiplied by its appropriate Complexity Correction Factor and the resulting FP values are summed to give total System BANG. DeMarco found the measure was not installation-independent and suggested that "the complexity weighting factors are, unfortunately, environment dependent" and that two of them, device management and computation. "you correct with your own estimate based on type of computation or type of device" lDEM821. He also suggests that "you will need to develop your own set of weightings and perhaps some of your own new classes" (DEM821. DeMarco in IDEM821 suggests a second method to obtaining System BANG. I f the system is data-strong i.e. one with a significant database then the BANG can be based on the count of objects in the dat.abase. Each object is corrected for the number of relationships at the object boundary and the corrected objects are then summed. For systems that are both data strong and function strong he suggests that the system should be divided, and two sets of BANG metrics be used. The two predictors should not be combined and the project should be treated as if it were actually twr, projects. He does not believe that there is any satisfactory way of combining Function BANG and Data BANG in the general case but that an individual installation may be able to get a procedure for relative scaling so that the two could be added together. System BANG h 3s some appeal as it is developed from specifications but the functional primitives are at such a low level that the information from it would not be available early enough to be as useful for feasibility sizing. System BANG ( at least from the published material) appears to be a general approach to a sizing method, that d n e r e n t users can customize in different ways, rather than a cookbook that they can follow. It is still too subjective and the work involved for a DP department to build up its own weightings and classes of primitives would prohibit wider use in its present form. This would result in the measure becoming too installation-dependent. We see the System BANG approach as a very promising one if it can be built into and automated specification tool so that it can be calculated automatically as specifications are developed. e.8. in conjunction with the Structured Systems Analysis and Design Method's MUST set of automated tciols being developed at present in the UK. Indeed, until ~t is automated, it 1s unlikely that it will be used at all widely. 3.0 An approach to software sizing. The software sizing and costing model shown in Figure 2 provides the framework for our research in software sizing. The great complexity of the whole sizing and costing problem. coupled with the relative success of the COCOMO model in costing from a given size, leads us to concentrate on the estimation of Zystem size in KDSI (thousands of delivered source instructions). Objections have been raised to KDSI as a system size measure [KAFSSI, ICOL821, IBRY8jl. However it has the great advantage of providing a measurable output of the sizing model and input to the costing model. A more fundamental objection can be raised in relation to the sizlng and costing framework shown in Figure 2, namely that it assumes that the sizing and costing processes are separable. This assumption has SO far been largely vindicated by the success of the COCOMO model. If further research showed that many significant cost drivers were also size drivers. it may have to be questioned. At this stage, we have restricted our attention to data processing applications, such as those commonly found in commercial processing. implemented in the organic mode. This has the advantage of greatly restricting variability within the domain of interest. It also has the pragmatic advantage for us of ready availabilty of empirical data. A complication is t.he increasing variety of languages in which data processing systems are now commonly written, including man); so--called fourth generation langu~ges. Often, more than one language is employed in a single system. We see the software sizing model as consisting of three main components, A. B and C, circled in Figure 2. The inputs to the sizing model are ( i ) the system model, which is as far as possible an abstract specification of the system free from implementation considerations or other similar constraints it describes what the system is to be, e.g in data flow diagrams, a data model, and associated dictionary entries A SOFTWARE SIZING AND COSTING MODEL